The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation. We have captured full system logs across three separate incidents. Below are the exact log sequences. Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams) Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA) The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app. 17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0 ↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min). 17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome ↑ LTE cell handover triggers RRC reconnect. 17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)] event: path:satisfied_change @594.391s ↑ APNs path re-satisfied. Reconnection begins. channel-flow viable NOT yet reached — TLS handshake still in progress. 17:48:08.057 apsd Powerd has requested assertion activity update ↑ Warning: powerd about to change policy. ── 2 minutes 40 seconds after APNs reconnect started ── 17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3 17:48:41.250 apsd Update assertion policy 3 17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0 17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0 ↑ Screen off, device locked. OS enters restricted idle. apsd restricted. APNs reconnection abandoned. 17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort nexus error (2) for pid 1518 Comera ↑ Kernel terminates Comera's network stack via NECP. No API available to prevent this. WhatsApp and Teams remain suspended — no DEFUNCT, but apsd in policy 3 means no push delivery for them either. ── Dead zone: VoIP pushes for all 3 apps undeliverable ── 17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive "com.apple.ipTelephony.sipIncoming.cell" ↑ Incoming cellular PSTN call forces system wake. 17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0 17:50:04.598 apsd Update assertion policy 0 ↑ Full wake. Queued VoIP pushes from Comera, WhatsApp, and Teams are delivered simultaneously. Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action. Working case (same test, different conditions) Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot 19:2x:xx apsd policy state {downgradeWhenLocked: NO, isSystemLocked: NO, isConnectedOnUltraConstrainedInterface: NO} ↑ Device unlocked. No policy 3. Comera NOT defuncted. Push delivered. Call rings normally. Our implementation PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement Questions Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario. Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd? Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window? What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period? Full log stream captures available for all incidents.

We are observing multiple different deviceId values linked to the same user within short timeframes. In some instances, a new deviceId appears every few minutes or hours. We utilize this identifier for managing Apple Wallet pass updates. We would appreciate understanding which scenarios might cause the deviceId to change. Could it be influenced by: Device restoration or factory reset procedures App reinstallation or data clearing iOS version updates iCloud account changes or Apple ID authentication status changes Privacy feature activation (such as App Tracking Transparency or Private Relay) Testing environment usage (simulators or automated testing frameworks) We aim to determine whether this behavior is expected or if it suggests atypical usage patterns. Thank you for your assistance!

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer

Problem Description We are encountering a pushToken retrieval failure when creating Live Activities using the ActivityKit framework in our iOS application. Problem Symptoms Failure Rate: Approximately 40% of Live Activities created in production fail to obtain a pushToken Behavior: The Activity is created successfully, but activity.pushToken and the activity.pushTokenUpdates stream remain empty / return nothing Impact: Unable to update Live Activities via APNS Offline Issue Environment iOS Version: iOS 26.5 Device: Physical iPhone device Deployment Environment: Production environment, release build Code Sample Task { // Executed after Live Activity creation for await activity in Activity<T>.activityUpdates { ... if let activityTokenData = activity.pushToken { // Report token to APNS service reportTokenToAPNS(tokenString) } // Start async monitoring self.registerPushTokenUpdates(...) Log("actObserver: Live Activity registered successfully") } } // Async monitoring private func registerPushTokenUpdates<T: SAKActivityAttributes>(...) { Task { self.pushTokenObserveRecords.safe{ $0.append(activity.id) } Log("Monitoring pushToken updates for Live Activity <\(activity.id)>") for await data in activity.pushTokenUpdates { let pushToken = pushTokenString(with: data) // Report token to APNS service reportTokenToAPNS(pushToken) } } } System Log Evidence System logs, log and log

so the app is free to download . the first use is free for two days . We want to send a reminder to them via email. some are installing (67%) but not returning to use the free credit. what is the policy on getting the apple id from apple. do we have to ask the user for the id at install and then disclose that its for tracking purposes and to inform about future promo's . the id will not be shared with third parties

Don’t spam

ubject: Walkie-Talkie App Not Working After Updating to iOS 27 Developer Version Dear Support Team, I am experiencing an issue with the Walkie-Talkie app after updating my device to the iOS 27 Developer Version. Since the update, the app is not functioning properly, and I am unable to connect or communicate with my contacts using Walkie-Talkie. I have already tried several troubleshooting steps, including restarting the device, checking my network connection, and verifying that both FaceTime and Walkie-Talkie are enabled. However, the issue still persists. Could you please help identify the cause of this problem and advise on any available solutions or known issues related to the iOS 27 Developer Version? Device Model: [IPHONE 17] iOS Version: iOS 27 Developer Version Issue Started: Immediately after updating to iOS 27 Developer Version Thank you for your assistance. I look forward to your response.

Hi everyone, I'm working on a Live Activity implementation for a ticketing app (written in Swift/SwiftUI with ActivityKit), and I've encountered an unexpected behavior on iOS 26.2.1 that contradicts my understanding of the documentation. What the docs say: The official ActivityKit documentation states: "The system uses the minimal presentation when more than one app has an active Live Activity." This implies the two minimal slots are intended for two different apps. There is no documented scenario where a single app occupies both minimal positions simultaneously. What I observed: On a device running iOS 26.2.1, with two active Live Activities from the same app running at the same time, both minimal views appeared on the Dynamic Island simultaneously — one attached to the island, one as a detached floating pill. Questions: Is this behavior intentional in iOS 26, or is it a regression / unintended side effect? Has the system policy changed in iOS 26 to allow a single app to occupy both minimal slots? If this is expected, is there any updated documentation or release notes that cover this change? Environment: Device: iPhone 14pro iOS: 26.2.1 Xcode: xcode26 Any insights from Apple engineers or developers who've seen this would be greatly appreciated. Thanks!

Populating widgets with silent push notifications would be great for us if they were more predictable. Can you share tips for debugging / testing in Test Flight beyond the usual recommendations available online? When messages are not processed it is a major challenge to distinguish between code problems and device throttling.

In an MSP environment, we manage hundreds of Mac based client organizations. It would be really helpful to have support in the Apple Business API for automating APNS certificate and ADE / Apps & Books token renewal. Thanks!

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

I'm building a macOS app and trying to confirm whether there's a way for me to remotely wake a Mac so my app can do a small amount of work (using APNs silent notifications or any other technique). Here's what I want to happen: User runs my app on their Mac User puts the Mac to sleep (Apple menu > Sleep) 30 minutes later, my server sends a push notification (content-available: 1, apns-push-type: background, apns-priority: 5) via APNs to the Mac Note: Power Nap and Wake for Network Access are enabled The Mac dark-wakes, delivers the notification to my app via application(_:didReceiveRemoteNotification:), my app gets ~30 seconds to open a WebSocket, do some work, and return Mac goes back to sleep So far, I've been able to send silent push notifications to a sleeping Mac, but my app only gets to take action on them after the Mac has been awoken manually. I've tried both silent pushes (content-available: 1, priority 5) and alert pushes (priority 10) with the same result. After trying every option I can find, I don't believe notifications can wake a sleeping Mac and allow my third-party app to process data, but I really want to be wrong. Can anyone confirm whether or not this is possible?

Environment: iOS 18.7.8, CallKit + PushKit VoIP. On VoIP push we call reportNewIncomingCall and show the system CallKit UI. Goal: When the user declines from the CallKit UI, send a single HTTPS POST to our backend in realtime, across all app states. Problem: Foreground and backgrounded states work. When the app is terminated (system-evicted or user-force-quit), the push launches the app, CallKit shows, and we receive CXEndCallAction — but the network request doesn't reliably leave the device. The process is suspended/terminated moments after the action returns. Tried: URLSession.shared dataTask inside CXEndCallAction — frozen with the app; resumes only on next foreground launch. beginBackgroundTask(withName:) around the request — insufficient when terminated. Background URLSession (.background, isDiscretionary = false, sessionSendsLaunchEvents = true, uploadTask(fromFile:), body staged in Caches, held briefly with a task assertion). Reliable when backgrounded; still unreliable/delayed when terminated, especially after force-quit. Questions: Is reliable, near-realtime client network delivery from a terminated, PushKit-launched app possible, or is this an inherent platform constraint? If it's a constraint, is the recommended pattern to treat the decline as best-effort and make the server authoritative (e.g., ring timeout)? Any official references? Does force-quit vs. system termination change background-execution / background-URLSession guarantees, and is there a supported approach for force-quit specifically? Any API we missed (e.g., a sanctioned way to extend runtime during CXEndCallAction, or background-URLSession scheduling guarantees for VoIP) that makes this realtime-reliable?

Platform and Version Platform: iOS iOS Version: 17.0+ Development Environment: .NET MAUI (C#, .NET 9) Network Layer: HttpClient with HttpClientHandler Description of the Problem We are facing an issue where HttpClientHandler.ServerCertificateCustomValidationCallback is not being invoked when the app is in a terminated (kill) state. In normal app lifecycle states (foreground/background), the callback is triggered as expected and allows us to handle server certificate validation (e.g., for certificate pinning or custom validation logic). However, when the app is in a killed state and is relaunched due to a notification action, the callback does not execute. We would like to understand: Why ServerCertificateCustomValidationCallback is not invoked in this scenario Whether this behavior is expected within iOS networking/runtime constraints Any recommended approach or workaround to ensure certificate validation still occurs when handling notification-triggered flows from a terminated state Steps to Reproduce Ensure the app is force-terminated (kill mode) Configure a push notification with category: "INVITE_CATEGORY" Include custom notification action buttons Tap one of the custom actions This triggers app launch and network call using HttpClient Expected Behavior ServerCertificateCustomValidationCallback should be invoked during the network request initiated after tapping the notification action, allowing custom certificate validation.

I am using AVAudioSession, AVAudioEngine and SpeechAnalyzer to listen to commands, also when the phone is locked. In the same time, I can receive PushNotifications with pre-defined sound. However, the pre-defined sound is not played when the AVAudioEngine is running and the phone is locked. In the code below, I have made many experiments, all of them are "Receive Push Notification while the phone is locked", and I have the following results: If audioEngine has started - I only see the alert, but no sound. If I comment out audioEngine.start, all works as expected and I hear the apns sound on the speaker. If I change the AVAudioSession category to 'record' I don't receive the push message at all! I wonder if anyone has seen it. Here is my code: private func doStartListening() async { print("SpeechService: doStartListening called") guard !audioEngine.isRunning else { print("SpeechService: Audio engine already running") return } do { try configureAudioSession() let recordingFormat = audioEngine.inputNode.outputFormat(forBus: 0) audioEngine.inputNode.removeTap(onBus: 0) guard let locale = await SpeechTranscriber.supportedLocale(equivalentTo: Locale(identifier: "en-US")) else { print("English is not supported on this device") return } let transcriber = SpeechTranscriber(locale: locale, preset: .transcription) if let installationRequest = try await AssetInventory.assetInstallationRequest(supporting: [transcriber]) { try await installationRequest.downloadAndInstall() } let (inputSequence, inputBuilder) = AsyncStream.makeStream(of: AnalyzerInput.self) let audioFormat = await SpeechAnalyzer.bestAvailableAudioFormat(compatibleWith: [transcriber]) let analyzer = SpeechAnalyzer(modules: [transcriber]) // Initialize the modern SpeechAnalyzer self.analyzer = analyzer task = Task { print("SpeechService: Starting analyzer results loop") do { for try await result in transcriber.results { if Task.isCancelled { break } self.handleAnalyzerResult(result) } } catch { print("SpeechService: Analyzer error: \(error.localizedDescription)") let nsError = error as NSError if nsError.domain == "kAFAssistantErrorDomain" && nsError.code == 203 { self.addLog(NSLocalizedString("error_siri_disabled", comment: "")) Task { await self.stopListening() } } else if self.isListening { self.restartRecognition() } } } audioEngine.inputNode.installTap(onBus: 0, bufferSize: 1024, format: recordingFormat) { [weak self]buffer, _ in guard let audioFormat else { return } do { let converted = try self!.converter.convertBuffer(buffer, to: audioFormat) inputBuilder.yield(AnalyzerInput(buffer: converted)) } catch { print("Exception when converting audio") } } audioEngine.prepare() try audioEngine.start() print("SpeechService: Audio engine started") try await analyzer.start(inputSequence: inputSequence) isListening = true addLog(NSLocalizedString("waiting_wakeup", comment: "")) } catch { print("SpeechService: Error starting listening: \(error.localizedDescription)") addLog("Error starting listening: \(error.localizedDescription)") lastError = error.localizedDescription isListening = false } } private func configureAudioSession() throws { let audioSession = AVAudioSession.sharedInstance() try audioSession.setCategory(.playAndRecord, mode: .default, options: [.mixWithOthers, .defaultToSpeaker]) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) }

Hi Team We are building a live activity feature for our app. While using the APNS broadcast API (https://api.push.apple.com:443/4/broadcasts/apps/), we are getting throttled. The updates are infrequent (sport games) and yet we are facing this issue. Our understanding was that the throughput is quite high but there is no documentation on the actual limitations. Furthermore, all of our updates are using a priority of 5. We have currently configured retry with exponential backoff and jitter but we would like to understand the APNS throttle limit for live activity broadcast. Is the limit per channel id or at API level? What is the hard limit for the API request per seconds? Can we request increase to the API rate limit?

Hi, We operate several iOS apps that use APNs through the HTTP/2 provider API. Since around May 12, we have observed a significant drop in APNs HTTP/410 “Unregistered” responses across multiple apps / bundle IDs. There have been no relevant changes on our side around that time. Our APNs integration, request flow, credentials, and push token handling have remained unchanged. What makes this more confusing is that App Store Connect does not show a corresponding drop in app deletion events for the same apps and time period. In other words, the app deletion trend appears stable in App Store Connect, but APNs 410 “Unregistered” responses dropped sharply. We understand that APNs does not guarantee an immediate 410 response after an app uninstall, and that the exact token invalidation timing is not documented. However, the aggregate change in 410 response volume is large enough that it looks like a behavior change. Questions: Has there been any recent APNs behavior change around when device tokens are marked inactive after an app is uninstalled? Were there any APNs-side changes around May 12 that could affect the rate of HTTP/410 “Unregistered” responses? Why might App Store Connect app deletion events remain stable while APNs 410 “Unregistered” responses drop significantly? Is APNs expected to return HTTP/200 for an extended period for tokens that may no longer be active for the topic? Thanks.

Hi everyone, I have two questions about Live Activity push notifications that we send from our backend server to iPhones. First, I would like to understand the expected behavior when lowering the APNs priority of a Live Activity update from 10 to 6. How does this affect delivery timing, reliability, or system handling of the notification? Second, my team has been seeing significant delays with some messages sent to the device. In some cases, notifications take anywhere from 1 to 3 hours to arrive on the phone. We are trying to understand what might cause this kind of delay. Is this expected under certain conditions, such as device state, system throttling, network conditions, or APNs behavior? Also, is there any way to inspect logs or delivery details for messages sent to the app so we can better diagnose where the delay is happening? Any guidance would be appreciated. Thanks.

1. Does the "important" description for silent notification in the documentation still valid? (Pushing background updates to your App) The system treats background notifications as low priority: you can use them to refresh your app’s content, but the system doesn’t guarantee their delivery. In addition, the system may throttle the delivery of background notifications if the total number becomes excessive. The number of background notifications allowed by the system depends on current conditions, but don’t try to send more than two or three per hour. I would like to implement notification that would wake up my application in all state to perform AVSpeechSynthesizer, but I am confused with the availability of the silent notification. I attempted to send silent notification to my ipad to see the exact behaviour, but it seems like it has not been throttle even after a few tens attempts within the same hour. { "aps": { "content-available": 1, "alert": { "title": "Title", "body": "Content"}, "sound": "default" } } 2. I am also confused if mixing the "content-available" key pair with "alert" in the aps payload will make the Heads-up Notification been throttle as well?

Does anyone know how long it usually takes for us to hear back from Apple regarding a request for Location Push Service Extension entitlement?